For assigning a smart card to a specific user, the smart card must be configured. Configuring a smart card means personalizing it with card specific data, for example cryptographic keys, certain IDs, or serial numbers. Thus, a configured smart card may be assigned to a certain user in accordance with the card specific data.
Card specific data may be stored in a non-volatile memory of the smart card. A non-volatile memory is typically implemented in form of EEPROM (Electrically Erasable Programmable Read Only Memory) or Flash technology. This type of memory is capable of storing up to several hundred Kbytes of data. In order to be able to manage such an amount of data, a file system-like architecture, for example a file structure as defined by ISO-7816, part 4, is needed. This file system is typically provided by an operating system (OS) of the smart card.
The file system of a non-volatile memory as such is initialized after the OS has been installed. Moreover, each OS has its proprietary file system. These limitations make it difficult to write card specific data in a non-volatile memory during the manufacturing process or during a pre-use configuring process. In order to overcome this drawback, installation of an OS and card specific data is performed in a complicated process. Two different approaches are known.
One approach is the so-called single-process approach. According to this approach, the OS and the card specific data are installed in one go. Usually, this process cannot be split up, because the OS and the card specific data may rely on each other. For example, the OS cannot be installed because cryptographic keys of the card specific data are needed, and the cryptographic keys cannot be installed because the OS is needed to provide the file system. The problem with this approach is the fact that different images including some OS data for every different smart card are required. An image means data stored in an EEPROM and in a ROM (Read Only Memory). Thus, even if finally configured smart cards differ only in one unique cryptographic key pair, different and entire images are needed to initialize the cards.
Another approach is the import of data structures after the OS was initialized. However, this approach has the problem that every smart card has to be handled twice. First, the OS must be initialized, and then the data must be initialized. For example, U.S. Pat. No. 4,874,935 discloses a way to make a smart card more flexible by storing an address table in the EEPROM of the smart card at the time of configuration or personalization, respectively. During operation of the smart card, the OS calls program instructions in accordance with the addresses indicated in the address table. Thus, it is possible to alter the programs stored in the ROM of the smart card.